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System for consulting and/or updating DNS servers and/or LDAP directories 

The present invention concerns a system for consulting and/or updating DNS (Domain 
Name System) servers and/or LDAP (Lightweight Directory Access Protocol) directories 
from a terminal. The present invention in particular enables a subscriber, from any terminal, 
to consult and update a telecommunication resource record stored in a DNS or LDAP server. 

DNS (and LDAP) servers are used in the data processing world for naming machines 
(for example: association of a web URL with an IP address corresponding to the web server 
storing this web site). These servers are usually consulted by data processing machines by 
means of software commonly called RESOLVER, available in the majority of terminals or 
data processing servers. This software makes it possible to extract information from a DNS 
server in response to the request from a client. This information may be available directly 
from the first DNS server consulted or from a DNS server referred to by the first, and so on if 
necessary by successive indirections. The contents of the DNS servers are updated by 
"administrator" specialists rather infrequently (updating of flat files under a UNIX platform or 
dedicated application via IHM under Windows server platforms). The format of the contents 
of the servers and requests are defined in a protocol, referred to as the DNS protocol, 
described in the documents RFC 1034 and RFC 1035, available on the IETF web site 
(www.ietf.org') . 

In addition, DNS servers are now called on to fulfil a role in the context of the ENUM 
service aimed at offering subscribers widespread portability of telephone numbers. This 
ENUM service uses the international telephone dialling system defined by the ITU under the 
reconrunendation E.164. More precisely, the ENUM service enables any subscriber having a 
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unique EJ64 telephone number (a telephone number of the type +33296053859) to be joined 
by various means according to his preferences configured in a profile stored in the network by 
a DNS server. For example, the unique E. 164 telephone number of the ENUM subscriber can 
be associated with a mobile telephone number (+33686166924), with a fixed telephone 
5 number (+33296916404), with an e-mail address (bertrand.dupont(S)Td.francetelecom.com) - 
with a web site URL fhttp://vyvyw.bertrand.dupont.com \ with a VoIP telephone number 
(sipibertrand.dupontC^sip.ft-ancetelecomxom), with a fax number, etc. 

All this information can be stored in a standard DNS server and accessed according to 
the hierarchical delegation model depicted in Fig. 1 . 

10 Access takes place through a root DNS server (E164.ARPA). Each country then has a 

unique telephone code (33 for France) and a DNS server is managed at level 1 by each 
country (3.3.E164.ARPA for France). Finally, telecommunications operators or ENUM 
service providers manage DNS servers (indicated in Fig. 1 by DNS 1 to DNS 6) according to 
the telephone resources (tranche of E.164 telephone numbers) which are allocated to them. 

15 The model adopted is a division by tranches: 5 tranches of fixed STN telephone numbers with 
prefixes ranging fi-om 1 to 5 and one tranche of mobile telephone numbers identified by the 
prefix 6. 

A path in the DNS server tree is associated with a telephone number to the E.164 
format. More precisely, each telephone number to the E.164 international format is reversed, 
20 the "+" code is omitted, a point is added between each digit and the result obtained is joined 
to the el64.arpa domain so as to transform the telephone number into a unique Internet 
domain name. For example, the telephone number +33686166924 gives, after transformation, 
the Internet domain name 4,2.9.6.6. 1 .6.8.6.3. 3. el 64. arpa. 

In addition, with each telephone number to the E.164 format there is associated a 

2 5 record comprising one or more resource records (Resource Record or RR) stored in the 

corresponding level 2 server, each resource record being able to comprise one or more fields. 
For example, with a telephone number to the E.164 format there can be associated NAPTR 
(Naming Authority PoinTeR) resource records as defined in the documents RFC 2915 and 
RFC 2916, available on the IETF site. Schematically, an NAPTR resource record indicates a 

3 0 telecommunication service (telephone or fax number, e-mail address, web site etc) associated 

with a priority level. The term ENUM record (or ENUM profile) will hereinafter be used for 
a set of NAPTR records associated with an Internet domain name. For example, if the 
following ENUM profile is stored in a level 2 DNS server: 
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SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 

IN NAPTR 100 10 'V "tel+E2U" "!^*$!tel:■f33296053859!" 

IN NAPTR 100 1 1 "u" "tel+E2U" "!^*$!tel:-h33296916404!'' 

IN NAPTR 100 12 'V "tel+E2U" "!^*$!tel:+336861 66924! 
5 IN NAPTR 100 13 "u" "sip+E2U" "!^.*$!sip,bdupont@sip.ftrd,fr!" 

IN NAPTR 120 10 'V "mailto+E2U" "!^.*$!mail2:bdupont@rd.ftrd.fr!" 
IN NAPTR 130 10 "u" "http+E2U" "!^.*$!http://www.bdupont.fr!" 

The header line indicates an Internet domain name corresponding to the E.164 
telephone nximber. The RESOLVER software makes it possible to access the record from the 
1 0 domain name. A telecommunication resource or service corresponds to each NAPTR record 
in the above example. Two numerical fields follow the term "NAPTR", it is a case 
respectively of the service priorities: "Order" and "Preference". The lower the value of the 
"Order" field, the higher the priority of the service and, if several services have an identical 
order level, the lower the associated preference value, the higher the priority of the service. 
15 Thus the above lines of record correspond to decreasing priorities. 

The 1^' line corresponds to the fixed telephone service 0296053859 with an order=100 
and a preference=10. 

The 2"^ line corresponds to the fixed telephone service 0296916404 with an order=100 
and a preference=l 1 . 

2 0 The 3"* line corresponds to the mobile telephone service 0686166924 with an 

order= 1 00 and a preference^ 12. 

The 4*** line corresponds to the IP telephone service via SIP to the SIP address 
bdupont(a)sip. ftrd.fr with an order=100 and a preference=13. 

The 5^^ line corresponds to the e-mail electronic mail service whose destination 
25 address is bdupont@rd.ftrd.fr with an order=l 20 and a preference=l 0. 

Finally, the 6*^ line corresponds to the web service whose access URL is 
h ttp :// w WW .bdupont . fr with an ordei:=130 and a preference=10. 

The meaning of this record is as follows. If it is sought to join the E.164 telephone 
number (+33296053859), the RESOLVER software transmits a request to the level 2 DNS 
30 server with the name of the corresponding Intemet domain (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). 
In return, the level 2 DNS server (DNS2) will supply in the response the list of 
telecommunication resources (also hereinafter referred to as services) associated with the 
telephone number +33296053859, as given by the record. The RESOLVER software and the 
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ENUM service can then exploit all or part of these resources in sequential mode (the system 
will attempt to join the service with the highest priority and then, in the absence of a response 
or in the case of the line being busy, the system will attempt to join the service of lower 
priority, etc) or in broadcast mode (the ENUM service will then attempt to join all the services 
5 simultaneously). 

The modification of the ENUM profiles in a DNS server does not adapt well to the 
method of updating by administrator as known firom the prior art. This is because, unlike 
Internet domain names, the conventional telecommunication services such as telephone or fax 
are liable to firequent change. What is more, it is sometimes necessary to program these 
10 changes automatically on a daily or even hourly base. It is then extremely difficult, for 
reasons of availability and flexibility, to have the changing configuration of an ENUM profile 
supported by its own telecommunications operator or its ENUM service provider. 

A particular problem at the basis of the invention is to enable a subscriber to have a 
simple and rapid consultation and/or modification of his ENUM profile stored in a DNS 
1 5 server or an LD AP directory. 

In more general terms, the problem at the basis of the invention is to allows a simple 
and rapid consultation and/or modification of one or more resource records stored in a DNS or 
LDAP server, and this fi-om any conventional terminal. 

The problem at the basis of the invention is resolved by a system for consulting and/or 
20 updating a record stored in a first database, the said record comprising one or a plurality of 
resource records, the said first database being stored by a domain name server, referred to as a 
DNS server, or a directory server, referred to as an LDAP server, able to be accessed by 
indirection fi*om a DNS server, the said system comprising: 

- communication means enabling the said system to receive ft-om a telecommunication 

2 5 terminal a request for consultation and/or modification of the said record or a programming of 

such a request; 

- control means adapted to determine, fi-om said consultation and/or modification 
request transmitted to the said system or previously programmed in the said system, a domain 
name and an operation to be performed on the said record; 

3 0 - protocol management means adapted to seek, fi-om the said domain name, the IP 

address of the said server storing the said first database and, according to the said operation, to 
transmit to the said server a request to read or update the said record. 

Advantageously, the said system comprises authentication means adapted to 
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authenticate at the application level the sender of the said request from authentication 
information stored in a second local or remote database. 

When the sender of the said request has been authenticated, the said protocol 
management means make it possible to transmit a consultation request according to the DNS 
protocol (DNS Query) to the said DNS server, the request having the said domain name as its 
argument, and to receive a first response from the said server. 

According to one embodiment, the control means are adapted to determine the said 
domain name from a subscriber identifier, which may be the E.164 telephone number of the 
said subscriber. 

The control means are then adapted to extract information and to determine, according 
to the said request, an operation to be performed on a resource record of the NAPTR type. 

According to other embodiments the control means are adapted to extract information 
and to determine, according to the said request, an operation to be performed on one or more 
resource records of the type A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, 
PTR, HINFO, MINFO, MX, TXT. 

The characteristics of the invention mentioned above, as well as others, will emerge 
more clearly from a reading of the following description of an example embodiment, the said 
description being given in relation to the accompanying drawings, amongst which: 

Fig. 1 illustrates schematically the delegation model used in the ENUM service; 

Fig. 2A illustrates schematically an example of an environment of the system 
according to the invention; 

Fig. 2B illustrates schematically the environment of Fig. 2A in the context of the 
ENUM service; 

Fig. 3 A depicts the outline diagram of the consultation/updating system according to 
the invention; 

Fig. 3B depicts an example of a consultation/updating system according to the 
invention; 

Fig. 4 depicts schematically a consultation and manual updating procedure for an 
ENUM profile with access in voice mode; 

Fig. 5 depicts schematically a consultation and manual updating procedure for an 
ENUM profile by sending SMS messages; 

Fig. 6 depicts schematically a consultation and manual updating procedure for an 
ENUM profile by the web; 
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Fig. 7 depicts schematically a consultation and manual updating procedure for an 
ENUM profile using a Minitel; 

Fig. 8 depicts schematically a consultation and manual updating procedure for an 
ENUM profile by e-mail; 
5 Fig. 9 depicts schematically a consultation and manual updating procedure for an 

ENUM profile by UUI from an ISDN terminal; 

Fig. 10 depicts schematically a procedure for programming the automatic updating of 
an ENUM profile; 

Fig. 1 1 depicts schematically a procedure for the automatic updating of an ENUM 

10 profile; 

Fig. 12 depicts schematically a procedure for consulting an ENUM profile when the 
latter is stored in an LDAP directory; 

Fig. 13 depicts schematically a procedure for updating an ENUM profile when the 
latter is stored in an LDAP directory. 
15 Fig. 2 A illustrates an example of an environment of the system according to the 

invention. 

Telecommunication resource management service providers, hereinafter referred to as 
service providers, have been shown schematically at 30|, . . ., 30n. Each service provider has a 
DNS server (31i) or LDAP server (34i) storing a database and more generally several 
2 0 redundant servers so as to increase the reliability of access to the service. The database 
contains a telecommunication resource record for all the service provider subscribers in 
question. 

The system (50) according to the invention can be connected on the one hand to the 
public telephone network via a standard interface of the analogue or digital type TO or T2 and 
25 on the other hand to the IP network via a standard interface of the Ethernet type. 

More precisely, the system (50) is connected to the Internet if the present invention is 
accessible to any subscriber, whatever his service provider, and can be connected to an 
Intranet if the present invention is accessible solely to subscribers of a service provider. 

The system (50) can be accessed by an ISDN telephone terminal (2) connected either 
30 directly or through a PABX (3) to the ISDN network (10). It should be stated that the ISDN 
network is interconnected natively to the STN network. 

The system (50) can also be accessed by means of a conventional telephone terminal 
(4) or a Minitel terminal (5) connected to the STN network (11). 
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The system (50) can also be accessed by a GSM mobile temiinal (6) or a UMTS 
temiinal, not shown (the GSM and UTRAN networks are interconnected natively to the STN 
network). 

The system (50) can be accessed by means of an IP telephone terminal (7) connected 
5 to the IP network (13). 

Finally, the system (50) can be accessed by means of a microcomputer (8) connected 
to the IP network either through an Ethernet interface (local business network) or by modem 
(STN/ISDN/ADSL/cable/satellite etc). 

The subscriber will also be able to receive notifications from the system (50) by virtue 
1 0 of one of the terminals envisaged above or by means of a fax terminal (9). 

Figure 2B illustrates an example of an environment of the system according to the 
invention, in the context of an ENUM service. The elements bearing the same reference 
numbers are identical to those of Fig. 2A. 

The level 0 (root) ENUM DNS server has been indicated at 40. This server has 
15 available all the IP addresses referencing all the level 1 ENUM DNS servers, corresponding to 
the codes of the various countries (33 for France, 34 for Spain, 44 for the UK etc). For 
example, 41 shows the level 1 ENUM DNS server corresponding to France. 

Each ENUM operator or service provider has at least one first level 2 ENUM DNS 
server (310, referred to as the primary server, with redundancy provided by at least one 
20 second level 2 ENUM DNS server (31^), referred to as the secondary server, in order to 
ensure good reliability of service. The primary (or respectively secondary) server stores a 
database 33i (or respectively 33 'i). In each level 2 server there is stored, for each E.164 
telephone number for a subscriber to the ENUM service, a profile composed of the various 
telecommunication resources of the subscriber, each resource corresponding to an access 

2 5 means (for example fixed office telephone, fixed home telephone, mobile telephone, IP 

telephone, office e-mail address, mobile e-mail address, business fax number, etc) as well as 
the priorities allocated to each of these access means. Each telecommunication resource is 
declared by means of an NAPTR resource record, as seen above. The priority of a resource is 
determined by the content of the Order and Preference fields of the NAPTR resource record, 

3 0 as defined in the document RFC 2915 of the IETF and exemplified in the introductory part. 

An ENUM service provider A (30i) can also have an LDAP server (34;) storing an 
LDAP dynamic directory (36i) as defined in the document RFC 1959 of the IETF. The 
advantage of this configuration is to make it possible to manage the ENUM profiles by 
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indirection not in the level 2 ENUM DNS but in the LDAP dynamic directory. The advantage 
procured consists of no longer modifying the profile of the ENUM client at the level 2 ENUM 
DNS server but directly in the LDAP directory, which for its part is designed to store dynamic 
profiles. In this case, the level 2 ENUM DNS (31i) contains for example the following profile 
for all the E.164 telephone numbers commencing with the prefix "+332": 

SORIGIN 2.3.3.el64.arpa. 

IN N APTR 1 00 1 0 "u" "ldap+E2U" 

"!^.+332(.*)$!ldap://ldap.providerA.fi-/cn=01!" 

The LDAP directory (36i) is accessed by indirection from the level 2 ENUM DNS 
server and contains the resource records for the various subscribers of provider A. 

An ENUM server or gateway (80) can consult an ENUM service provider (30i) in 
order to know the list of telecommunication resources of an ENUM subscriber. To do this, 
the RESOLVER software transforms the E.164 unique number of the subscriber into a 
domain name as seen above and by successive indirections accesses the level 2 ENUM DNS 
server (310 and, where applicable, after supplementary indirection to the LDAP server (34i). 
The service provider returns the list of resources of the subscriber in question with the 
associated priorities. The ENUM server or gateway (80) can then, according to 
circumstances, attempt to join the subscriber by successively using the resources, in 
decreasing order of priority, or join the subscriber by means of all his resources. 

Fig. 3A shows the outline diagram of the updating system (50) according to the 
invention. 

The system comprises communication means (1 150) enabling a subscriber to dialogue 
with the said system and in particular: 

to transmit an authentication request to the subscriber; 

to receive from the said subscriber information allowing his authentication; 

receiving from the said subscriber a request to modify a record (referred to as a 

manual request) or a request for automatic modification (referred to as a 

programmed request) according to a time or geographical criterion; 

to transmit the content of a record prior or subsequent to the modification request; 

to transmit to the said subscriber an update confirmation of location when the 

modification requested has indeed been made and update invalidation when it has 

not been able to be made; 

to transmit to the said subscriber, at the end of consultation or review, an automatic 
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modification request previously recorded in the said system; 

to transmit to the said subscriber a history of modifications made. 
The system also comprises interface means (1160) for connecting the said 
communication means to the STN/ISDN network and/or to an IP network (Internet or 
Intranet). 

The system also comprises authentication means (1173) cooperating with the 
communication means in order to authenticate at the application level a sender of a 
consultation and/or update request. Authentication at the application level has the advantage 
of enabling a subscriber to operate from any terminal. The authentication means use to do 
this authentication information stored in a local or remote database (1 170). 

Apart from the above-mentioned information, the database (1170) can in particular 
contain automatic modification programs relating to various subscribers, the IP addresses of 
the servers of the various telecommunication resource management providers, the histories of 
manual or automatic modifications of the records and the addresses to which the update 
confirmation/invalidation notifications must be sent. 

The system (50) also comprises protocol management means (1 162) fulfilling amongst 
others the RESOLVER function. In particular the protocol management means are adapted to 
seek, where necessary by successive indirections, the content of a resource record (RR) by 
means of a domain name. The protocol management means can for this purpose transmit 
consultation requests according to the DNS protocol (DNS Query). In addition, the protocol 
management means can update resource records from update requests (DNS Update). 
According to one embodiment, if the resource records are stored in an LDAP directory, the 
protocol management means will also allow consultation of a record in an LDAP directory 
(sending of an LDAP Search request) as well as the updating of this record (sending of an 
LDAP Modify request). When the updating has been performed, the protocol means receive 
acknowledgement fi-om the server of the telecommunication resource management provider. 

The control means 1 175 coordinate the aforementioned means and in particular: 

- order from the communication means the transmission of an authentication request; 

- after authentication of the subscriber by the authentication means (1 173), request the 
protocol means (1 162) to transmit a consultation request, format the response and retransmit it 
in intelligible form to the subscriber via the communication means; 

- from a request to modify a resource record by a subscriber, determine an operation to 
be performed on the said record and an identifier of the subscriber; 
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- on reception of update confirmation/invalidation by the protocol means, notify the 
conformation/invalidation to the subscriber via the communication means. 

Fig. 3B illustrates an example embodiment of the invention in the context of an 
ENUM service. 

The elements beeiring the same reference numbers are identical to those of Fig. 2 A. In 
particular, the subscriber can contact the updating system (50) by means of one of the 
terminals envisaged above. There is shown at (30) a telecommunication resource 
management service provider comprising a level 2 DNS server (31), referred to as the primary 
server, with redundancy provided by a secondary server (not shown). The server (31) 
comprises a database (33) and a DNS protocol stack (32) integrating the DNS protocols 
described in the documents RFC 1034 and RFC 1035. The protocol stack also integrates the 
DNS protocols described in the documents RFC 2136 and RFC 2137 intended to allow the 
updating (DNS Update) of a resource record (RR). Optionally, the resource management 
service provider also comprises an LDAP directory server (34) storing a database (36). The 
LDAP directory server comprises an LDAP protocol stack (35). 

The communication means of the system (50) consist of the following modules: 
o a module responsible for the processing of the incoming and outgoing telephone 
calls (52). This module manages the establishment and dropping of the 
communication; 

o a user to user information (UUI) management module (53) for extracting and 

transmitting UUI information; 
o a module (54) for processing DTMF codes. This module is responsible for 

recovering the DTMFs entered by the subscriber; 
o a voice synthesis module (55); 

o a module (56) for broadcasting pre-recorded voice files concatenated in order to 

form sentences; 
o a videotex server (57); 

o a module for receiving and sending SMSs (58); 
o a fax sending module (59); 

o an SMTP server (61 ) for sending and receiving e-mail; 
o a dynamic Web server (63). 

It should be noted that the system can also comprise a voice recognition module (not 
shown) adapted to recognise information pronounced by the subscriber. 
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The communication means are connected to the outside by means of an STN and/or 
ISDN interface (51) and an IP interface (60). The first is based either on a multiport STN 
analogue card or on a TO (2 channel) or T2 (30 channel) ISDN card. The second is an 
Ethernet interface. The gateway indicated by (14) states that the STN/ISDN and IP networks 
5 are natively interconnected in VOIP protocol (H323/SIP). 

The system (50) comprises, as before, authentication means (73) allowing the 
applicative authentication of subscribers to the service from authentication information, for 
example pairs of pseudonyms (Login_Id) and passwords stored in a local or distant database 
(70). In addition, the database comprises the identifiers of the various ENUM service 
10 providers (such as 30), the IP addresses or the machine names of the two-tier DNSs, requests 
for automatic modification of an ENUM profile, the histories of manual or automatic 
modification of ENUM profiles, and the addresses of notification of modification of the 
ENUM profile (fax N^, SMS, e-mail). 

The system also comprises a DNS protocol management module (62), preferably in its 
15 secure form (DNSSec). This module in particular fiilfils the role of RESOLVER for reading 
the resource records. 

Where necessary, an LDAP protocol management module (64) is added thereto to 
allow reading and modification of records in an LDAP directory. 

The system also comprises a module (72) for configuring the addresses of the level 2 

2 0 DNS servers and a module (71) responsible for updating the manual or automatic 

modifications of the ENUM profiles and where necessary to produce statistics for exploiting 
the system. 

The control means consist firstly of a module (74) responsible for the automatic 
configuration of ENUM profiles from automatic modification requests programmed by 
25 subscribers and stored in the database (70) and secondly a module (75) responsible for the 
"manual" configuration of the ENUM profiles. The latter manages ENUM scripts, in 
particular an ENUM profile reading script (it will be recalled that an ENUM profile consists 
of a list of NAPTR resource records), scripts for modifying the NAPTR resource record fields 
and in particular order, preference and service fields (e-mail address, telephone number, e- 

3 0 mail address etc). If it is wished to provide the consultation and/or updating of DNS resource 

records other than NAPTR, supplementary scripts must be provided for their modification. 

Fig. 4 illustrates schematically a procedure for the consultation and manual 
modification of an ENUM profile in voice mode via a fixed or mobile telephone of the STN, 
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ISDN, GSM or IP type. 

The ENUM subscriber at step 100 sends a free telephone call (green number type) or a 
paid one according to a geographical or fixed-rate remuneration of the audiotel or coloured 
numbers type from a fixed STN (4) or ISDN (2) terminal connecting to the public network or 
5 behind a PABX (3) or a mobile terminal (6) of the GSM type, or from an IP terminal (7) 
destined for the STN/ISDN interface (51) of the system (50). The automatic call processing 
controller (52) automatically accepts the incoming call at step 101. The ENUM script module 
(75) at step 102 gives the order to the voice synthesis module (55) or to the voice file 
broadcast module (56) to broadcast to the ENUM subscriber at step 103 a voice 

10 announcement inviting the ENUM subscriber to enter his E.164 ENUM number as well as his 
pseudonym and password. The ENUM subscriber at step 104 enters via his keypad this 
information which is conveyed in the band in the form of DTMF and which is intercepted by 
the DTMF processing module (54). This information is supplied at step 105 to the 
authentication module (73), which interrogates the local or remote database (via for example 

15 an interface of the ODBC type (standing for Open DataBase Cormectivity)), making a search 
on the E.164 ENUM niimber. This supplies, at step 107, the corresponding authentication 
information to the authentication module (73). The latter compares the pseudonym and 
password entered by the ENUM client with the authentication information contained in the 
database (70). In the event of agreement, the authentication module (73) at step 108 orders 

20 the voice synthesis module (55) or the voice file broadcast module to broadcast to the ENUM 
subscriber at step 109 an aimouncement of the type "In order to consult your ENUM profile 
hit the 1 key, to modify the attributes of your profile hit 2, to automatically configure your 
profile hit 3, to modify your pseudonym/password hit 4, to access your profile modification 
journal hit 5," etc. If the ENUM subscriber hits the 1 key on his telephone keypad at step 110, 

25 the corresponding DTMF code is intercepted by the DTMF processing module (54) and is 
retransmitted at step 111 to the ENUM script module (75). The ENUM script (75) then 
detects that it is a case of an ENUM profile reading command. The ENUM script (75) then at 
step 112 sends an interrogation request to the DNS protocol module (62) supplying as an 
argument the E. 1 64 address of the ENUM subscriber put in domain form (conversion of the 

30 E.164 telephone number of the type 33296053859 into (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). The 
DNS protocol management module (62), which fiilfils the conventional role of a RESOLVER, 
can first of all check whether the information is present in its cache following a previous 
consultation or interrogate (at step 1 13), according to the DNS standard protocol (DNS Query 
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request), successively the level 0 DNS server, the level 1 DNS server, and then the level 2 
DNS server by the DNS protocol stack (32). In order to gain in efficiency, the data of an 
NAPTR record are loaded into the random access memory of the DNS server (21). If the 
ENUM subscriber is actually recorded in the DNS server (31) of the ENUM service provider 
5 (30) then the DNS protocol stack (32) returns (at step 1 14) to the DNS protocol module (62) 
the list of corresponding NAPTR records. The DNS protocol module (62) is then responsible 
for retransmitting them to the ENUM script module (75) at step 115. The module (75) 
analyses and interprets the NAPTR records and generates a text which can be understood by 
the ENUM subscriber of the "Service N"" 1 : telephone to 0296053859, service N"* 2: telephone 
10 to 0686166924, service N° 3: e-mail to bertrand.duDont(g)rd.francetelecom.com /' etc type. 
This text is sent to the voice synthesis module (55) at step 116, which is responsible for 
broadcasting this information to the ENUM subscriber at step 117. In the case where the 
voice file broadcast module (56) is used, the module (75) generates the concatenation of the 
voice files to be played. 

15 After broadcasting this information, the voice synthesis module (55) or the voice file 

broadcast module (56) once again broadcasts at step 118 the list of possible administration 
operations on the ENUM profile "In order to consult your ENUM profile hit the 1 key, to 
modify the attributes of your profile hit 2, to automatically configure your profile hit 3, to 
modify your pseudonym/password hit 4, to access your profile modification journal hit 5," 

20 etc. 

If the ENUM subscriber chooses the modification of his ENUM profile at step 1 50, 
this command is intercepted by the ENUM script module (75) at step 151, following the 
detection of the DTMF code by the DTMF processing module (54). The system (50) then 
enters an iterative dialogue based on the broadcast of voice messages to the ENUM subscriber 
25 from a text generated by the ENUM script module (75) (at step 152) according to the context 
and broadcast (at step 1 53) in voice form by the voice synthesis module (55) or by the module 
for broadcasting concatenated voice files (56). The latter validates the choices offered using 
its DTMF keypad at step 1 54 and the commands are transmitted at step 1 55 to the ENUM 
script (75). For example, the voice dialogue may be as follows: 
3 0 o -> in order to modify the order/preference of your services hit 1 , to modify the 

attributes of a service hit 2, to add a service hit 3, to delete a service hit 4, etc. 
o ^4 

o in order to delete the telephone number 0296053859 hit 1, to delete the 
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telephone number 0686166924 hit 2, to delete the e-mail address 
bertrand.dupont@rd.francetelecom.com hit 3, etc. 
o ^2 

o To validate your choice hit 1, otherwise hit 2 
o ^ 1 

o ^ To delete a service hit 1, to record your cheuiges hit 2, to return to the main 

menu hit 0 
o ^ 2 

When the ENUM subscriber requests the changes to the ENUM profile to be taken 
into account, the ENUM script module (75) sends a modification demand request at step 156 
to the DNS protocol module (62). The latter sends a command DNS UPDATE at step 157 to 
the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). 
The IP address of the latter is stored in the database (70) and is foimd from the E.164 number 
of the ENUM subscriber. The DNS protocol module (32) updates the information in the 
random access memory of the server (31) and requests the updating of the database (33), 
which is generally a flat text file. The DNS protocol manages the modification number in this 
file so that the secondary DNS or DNSs can themselves reload this modification at predefined 
intervals of time. The database (33) confirms the updating at step 159, which results in a 
response to the demand request of step 160. The ENUM script (75) at step 116 intercepts the 
return code of this response and then at step 162 generates the confirmation/invalidation 
message regarding taking the modification into account. The voice synthesis module (55) or 
the voice file broadcast module broadcasts this information to the ENUM subscriber at step 
163. The latter can then release the communication. 

According to a variant of this procedure, in response to the voice messages, the 
subscriber can directly supply a response vocally. It is then the voice recognition module 
which determines the choice or the information contained in the response. 

Fig. 5 illustrates schematically the procedure for consultation and manual modification 
of an ENUM profile via the sending of SMSs from mobile or fixed telephone terminals of the 
GSM, STN, ISDN or IP type. The ENUM subscriber at step 200 sends a formatted SMS 
(e.g.: E.164 N° + pseudonym + password + request) as specified by the ENUM service 
provider (30) from a fixed STN (4) or ISDN (2) terminal connected to the public network or 
behind the PABX (3) or a mobile terminal (6) of the GSM type, or from an IP terminal (7), to 
the SMS module (58) of the present invention. The latter transmits the SMS at step 201 to the 
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ENUM script module (75). This information is supplied at step 202 to the authentication 
module (73), which at step 203 interrogates the local or remote database (via an ODBC 
interface for example) making a search on the E.164 ENUM number. This supplies the 
corresponding information at step 204 to the authentication module (73), which is responsible 
5 for comparing the pseudonym and password entered by the ENUM client in the SMS with the 
authentication information contained in the database. In the case of agreement, the 
authentication module (73) at step 205 orders the ENUM script module (75) to process the 
request contained in the SMS. The ENUM script (75) detects that it is a case of a command to 
read the ENUM profile. Consequently the ENUM script (75) sends an interrogation request at 

10 step 206 to the DNS protocol management module (62), applying as an argument the E.164 
address of the ENUM subscriber converted in the form of a domain (conversion of the E.164 
telephone number of the type 33296053859 into (9.5. 8.3.5.0.6.9.2. 3.3. el64,arpa)). The DNS 
protocol management module (62), which fulfils the conventional role of a RESOLVER, 
interrogates (step 207) by means of a request (DNS Query) the level 0 DNS server, and then 

15 the level 1 DNS server, unless the information is already in its cache following a previous 
consultation of these servers. To gain in efficiency, the data of a DNS server are loaded into 
the random access memory of the server (21). If the ENUM subscriber is actually recorded in 
the DNS server (31) of the ENUM service provider (30), then the DNS protocol module (32) 
at step 208 returns the corresponding NAPTR records. The DNS protocol management 

20 module (62) is then responsible for retransmitting them to the ENUM script module (75) at 
step 209. The latter analyses and interprets the NAPTR records and generates a relatively 
synthetic text understandable to the ENUM subscriber (of the type "PI : Tel=0296053859, P2: 
Tel=0686 166924, Pe: e-mail= bertrand.dupont(g)rd. francetelecom.com . P4: 

url=www.bertranddupont.fr, etc). This text is sent at step 210 to the SMS sending module 

25 (58), which sends the SMS (at step 21 1) to the telephone terminal originating the request (use 
of the Number of the caller). 

At step 250 the ENUM subscriber sends a formatted SMS message (e.g. E.164 N° + 
pseudonym + password + request type = ECR: PI: Tel=0686 166924, P2: 
bertrand.dupont(g!rd.francetelecom.com ) as specified by the ENUM service provider (30) 

30 from a fixed STN (4) or ISDN (2) terminal connected to the public network or behind the 
PABX (3) or a mobile terminal (6) of the GSM type, or from an IP terminal (7) to the SMS 
module (58) of the present invention. The latter transmits the SMS message at step 251 to the 
ENUM script module (75). This information is supplied at step 252 to the authentication 
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module (73) which at step 253 interrogates the local or remote database (via an OBDC 
interface for example) making a search on the E.164 ENUM number. This supplies the 
corresponding information at step 254 to the authentication module (73), which is responsible 
for comparing the pseudonym and password entered by the ENUM client in the SMS message 
5 with the authentication information contained in the database. In the case of agreement, the 
authentication module (73) warns the ENUM script module (75) of this, which then processes 
the request contained in the SMS. The ENUM script (75) detects that it is a case of a 
command to update the ENUM profile with arguments. The ENUM script (75) checks the 
syntax of the command and, if it is correct, sends an update request at step 256 to the DNS 

10 protocol management module (62). The latter sends a DNS UPDATE command at step 257 
to the DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). 
The IP address of the latter is stored in the database (70) and is found from the E. 1 64 number 
of the ENUM subscriber. The DNS protocol module (32) updates the information in the 
random access memory of the server (31) and requests the updating of the database (33), 

15 which is generally a flat text file. The DNS protocol manages the modification number in this 
file so that the secondary DNS server or servers can themselves reload this modification at 
predefined intervals of time. The server (31) confirms the updating at step 259, which results 
in a response to the update demand request at step 260. The ENUM script (75) at step 261 
intercepts the return code of this response and then at step 262 generates the 

2 0 confirmation/invalidation message relating to taking into account the modification before 

sending it to the SMS sending module (58), which is responsible for sending the SMS at step 
263 to the telephone terminal originating the request (use of the number of the caller). 

Fig. 6 illustrates schematically the procedure for consultation and manual modification 
of an ENUM profile by the web using a terminal having available a web browser (8). 
25 The ENUM subscriber at step 300 requests the downloading of the web home page of 

the ENUM profile management service. This is returned at step 301 by the web server (63) of 
the present invention. This web page displays an authentication form to the ENUM 
subscriber. The latter enters his E. 1 64 number and then his pseudonym and password. This 
information is transmitted at step 302 to the web server (63), which itself transmits it at step 

3 0 303 to the authentication module (73). The authentication module (73) at step 304 

interrogates the local or remote database (via an ODBC interface for example), making a 
search on the E.164 ENUM number. This supplies at step 305 the corresponding information 
to the authentication module (73) which is responsible for comparing the pseudonym and 
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password entered by the ENUM client in the web form and the authentication information 
contained in the database. In the case of agreement, the authentication module (73) at step 
306 notifies the web server module (63) that the authentication has succeeded. This sends at 
step 307, to the ENUM script module (75), a request to read the ENUM profile. 
5 Consequently the ENUM script (75) sends an interrogation request at step 308 to the DNS 
protocol module (62), supplying as an argument the E.164 address of the ENUM subscriber 
transformed in the form of a domain (transformation of the E.164 telephone number of the 
type 33296053859 into 9.5.8.3.5.0.6.9.2,3.3.el64.arpa), The DNS protocol module (62) 
which fulfils the conventional role of a RESOLVER interrogates (at step 309) after having 

10 checked whether the information is present in its cache following a previous consultation, 
using the DNS standard protocol (DNS Query request) successively the level 0 DNS server, 
the level 1 DNS server and then the level 2 DNS server. To gain in efficiency, the data of a 
DNS are loaded into the random access memory of the DNS server (31). If the ENUM 
subscriber is actually recorded in the DNS (31) of the ENUM service provider (30), the DNS 

15 protocol module (32) retums at step 310 the NAPTR records corresponding to the DNS 
protocol module (62). The latter retransmits them to the ENUM script module (75) at step 
311, which interprets the NAPTR records and generates a relatively synthetic text 
understandable to the ENUM subscriber, of the type: 
Priority 1 service Tel: 0296053859 

2 0 Priority 2 service Tel: 0686166924 

Priority 3 service Mail: b.dupont(S)Td.ft.com 
Priority 4 service Web: www.bertranddupont.fr 

This text is sent at step 312 to the web server module (63), which downloads a web 
page provided with this information at step 313 to the Web terminal (8) of the ENUM 
2 5 subscriber. 

The web page presented to the ENUM subscriber makes it possible, via an adapted 
graphical interface, to make normal ENUM profile changes: changes to priorities, addition of 
service, deletion of service, modification of the attributes of a service, etc. The modification 
request is sent at step 350 to the web server (63). The latter at step 351 transmits the request 
30 to the ENUM script module (75) which is responsible for formatting the request in accordance 
with the NAPTR inputs described by the ENUM protocol. The ENUM script (75) then sends 
an update request at step 352 to the DNS protocol module (62). The latter sends a conmiand 
DNS UPDATE at step 353 to the DNS protocol module (32) of the DNS server (31) of the 
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ENUM service provider (30). The IP address of the latter is stored in the database (70) and is 
found from the E.164 number of the ENUM subscriber. The DNS protocol module (32) 
updates the information in the random access memory of the server (31) and requests the 
updating of the database (33), which is generally a flat text file. The DNS protocol manages 
5 the modification number in this file so that the secondary DNS server or servers can 
themselves reload this modification at predefined intervals of time. The database (33) 
confirms the updating at step 355, which results in a response to the update demand request at 
step 356. The ENUM script (75) at step 357 intercepts the return code of this response and 
then at step 358 generates the confirmation/validation method relating to the taking into 

10 account of the modification before sending it to the web server (63), which is responsible for 
formatting the result web page before downloading it to the web terminal (8) at step 359. 

Fig. 7 illustrates schematically the procedure for consultation and manual modification 
of an ENUM profile from a Minitel. 

The ENUM subscriber connects to the Minitel service using the PAVI (Videotex Point 

15 of Access) frinction of the France Telecom network (for example calling the ENUM-FT code 
3615). The minitel terminal (5) then goes into session with the minitel server (57) at step 400. 
The latter at step 401 activates the ENUM script module (75) of the present invention, which 
then generates the home page of the service at step 402 and which is downloaded at step 403 
onto the Minitel terminal (5) of the ENUM subscriber. This Minitel page displays an 

2 0 authentication form for the ENUM subscriber. The latter enters his E.164 ENUM number and 

then his pseudonym and password. This infomiation is transmitted at step 404 to the Minitel 
server (57), which itself transmits it to the ENUM script module (75) at step 405. The latter 
redirects the request at step 406 to the authentication module (73), The authentication module 
(73) at step 407 interrogates the local or remote database (via an ODBC interface for 
25 example), making a search on the E.164 ENUM number. At step 408 the authentication 
information for the database is transmitted to the authentication module (73), which compares 
them with the pseudonym and password entered in the Minitel form. In the case of 
agreement, the authentication module (73) at step 409 notifies the ENUM script module (75) 
that the authentication has succeeded. The ENUM script module (75) then sends an 

3 0 interrogation request at step 410 to the DNS protocol module (62), supplying as an argument 

the E.164 address of the ENUM subscriber transformed in the form of domain (transformation 
of the E.164 telephone number of the type 33296053859 into 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). 
The DNS protocol module (62), which ftilfils the conventional role of a RESOLVER, 
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interrogates (step 411), after having checked whether the information is present in its cache 
following a previous consultation, using the DNS standard protocol (DNS Query request) 
successively the level 0 DNS server, the level 1 DNS server and then the level 2 DNS server. 
Preferably, in order to gain in efficiency, the data of a DNS are loaded into the random access 
5 memory of the DNS server (31). If the ENUM subscriber is actu£dly registered in a DNS 
server (31) of the ENUM service provider (30), the DNS protocol module (32) returns (at step 
412) the corresponding NAPTR records. The DNS protocol module (62) is responsible for 
retransmitting them to the ENUM script module (75) at step 413. The latter analyses and 
interprets the NAPTR records and generates a relatively synthetic text understandable to the 

10 ENUM subscriber, of the type: 

Priority 1 service Tel: 0296053859 
Priority 2 service Tel: 0686166924 
Priority 3 service Mail: b.dupont@rd.ftxom 
Priority 4 service Web: www.bertranddupont.fr 

15 This text is sent at step 414 to the videotex server module (57), which is responsible for 
downloading at step 415 to the Minitel terminal (5) of the ENUM subscriber. 

The videotex page presented to the ENUM subscriber makes it possible, via an 
adapted interface, to make modifications to the normal ENUM profile: changes to priorities, 
addition of service, deletion of service, changes to attributes of a service, etc. The request to 

20 update the ENUM profile is sent at step 450 to the videotex server (57). The latter at step 451 
transmits the request to the ENUM script module (75), which is responsible for formatting the 
request in accordance with the NAPTR inputs described by the ENUM protocol. The ENUM 
script (75) then sends an update request at step 452 to the DNS protocol module (62). The 
latter sends a command DNS UPDATE at step 453 to the DNS protocol module (32) of the 

25 DNS server (31) of the ENUM service provider (30). The IP address of the latter is stored in 
the database (70) and is found from the E.164 number of the ENUM subscriber. The DNS 
protocol module (32) updates the information in the random access memory of the server (31) 
and requests the updating of the database (33), which is generally a flat text file. The DNS 
protocol manages the modification number in this file so that the secondary DNS server or 

3 0 servers can themselves reload this modification at predefined intervals of time. The database 
(33) confirms the updating at step 455, which results in a response to the update demand 
request at step 456. The ENUM script (75) at step 457 intercepts the return code of this 
response and then generates at step 458 the confirmation/invalidation message relating to the 
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taking into account of the modification before sending it to the videotex server (57), which is 
responsible for formatting the resuh videotex page before downloading it at step 459 to the 
Minitel terminal (5). 

Fig. 8 illustrates schematically the procedure for consultation and manual modification 
5 of an ENUM profile by e-mail of a terminal having an e-mail client (8). 

The ENUM subscriber sends a formatted e-mail at step 500 to the e-mail server (61). 
The ENUM coirunand is for example made in the destination e-mail address: 
el64-33296053859-login-dupont-password-1234-request 
lire@gestion.enum.francetelecomxom 

10 The ENUM script module (75) has an e-mail client which regularly scrutinises the e- 

mail server (61), When the ENUM script module (75) at step 501 receives an e-mail as 
indicated above, it recovers, either in the header or in the body of the e-mail, the arguments 
supplied and then transmits them at step 502 to the authentication module (73). The 
authentication module (73) at step 503 interrogates the local or remote database (via an 

15 ODBC interface for example), making a search on the E.164 ENUM number. The latter at 
step 504 supplies the corresponding authentication information to the authentication module 
(73), which compares it with the pseudonym (login_id) and the password supplied by the 
ENUM client in the e-mail. In the case of agreement, the authentication module (73) advises 
the ENUM script module (75) of this at step 505. Consequently the ENUM script (25) sends 

20 an interrogation request at step 506 to the DNS protocol management module (62), supplying 
as an argument the E.164 address of the ENUM subscriber transformed into domain name 
(transformation of the E.164 telephone number of the type 33296053859 into 
9.5.8.3. 5.0.6.9.2.3.3.el64.arpa). The DNS protocol management module (62), which fiilfils 
the conventional role of a RESOLVER, interrogates (step 507), if however the information is 

25 not already present in its cache following a previous consultation, according to the DNS 
standard protocol (DNS Query request) successively the level 0 DNS server, the level 1 DNS 
server and then the level 2 DNS server by the DNS protocol stack (32). Preferably, in order to 
gain in efficiency, the data of a DNS are loaded into the random access memory of the DNS 
server (31). If the ENUM subscriber is actually recorded in the DNS (31) of the ENUM 

3 0 service provider (30), then the DNS protocol management module (32) at step 508 returns the 
corresponding NAPTR records. The DNS protocol management module (62) is responsible 
for retransmitting them to the ENUM script module (75) at step 509. The latter analyses and 
interprets the NAPTR records and generates a relatively synthetic text understandable to the 
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ENUM subscriber, of the type: 

Priority 1 service Tel: 0296053859 

Priority 2 service Tel: 0686 1 66924 

Priority 3 service Mail: b.dupont@.rd.ft.com 
5 Priority 4 service Web: www.bertranddupont.fr 

This text is despatched (step 510) in e-mail form by the e-mail client software 
integrated in the ENUM script module to the e-mail server module (61), which is responsible 
for sending it to the ENUM subscriber. 

The ENUM subscriber who wishes to modify his ENUM profile sends an e-mail 
10 formatted at step 550 to the e-mail server (61). The ENUM command is for example made in 
the destination e-mail address, for example: 

E164-33296053859-login-dupont-password-1234-request-write-Pl-tel-0296053859- 
P2-tel-0686166924-P3-fax-0296050242@gestion.enum.francetelecom.com. 

The e-mail client of the ENUM script module scrutinises the e-mail server (61). When 
15 the ENUM script module receives (at 551) an e-mail as indicated above, it recovers, either in 
the header or in the body of the e-mail, the arguments supplied and then transmits them at step 
552 to the authentication module (73). The authentication module (73) at step 553 
interrogates the local or remote database (via an ODBC interface for example), making a 
search on the E.164 ENUM number. This supplies at step 554 the corresponding 

2 0 authentication information and the authentication module (73) compares it with the 

pseudonym and password supplied in the e-mail. In the event of agreement, the 
authentication module (73) advises the ENUM script module (75) of this at step 555. The 
latter formats the request in accordance with the NAPTR inputs described by the ENUM 
protocol. The ENUM script (75) then transmits an update request at step 556 to the DNS 
25 protocol management module (62), which sends a DNS UPDATE command at step 557 to the 
DNS protocol module (32) of the DNS server (31) of the ENUM service provider (30). The 
IP address of the latter is stored in the database (70) and is found from the E.164 number of 
the ENUM subscriber. The DNS protocol module (32) updates the information in the random 
access memory of the server (31) and requests the updating of the database (33), which is 

3 0 generally a flat text file. The DNS protocol manages the modification number in this file so 

that the secondary DNS server or servers can themselves reload this modification at 
predefined intervals of time. The database (33) confirms the updating at step 559, which 
results in a response to the update demand request at step 560. The ENUM script module (75) 
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at step 561 intercepts the return code of this response and then generates the 
confirmation/invaHdation message relating to the taking into account of the modification. 
This message is sent (at step 562) in the form of e-mail by the client software integrated in the 
ENUM script module to the e-mail server (61). The latter at step 563 sends the e-mail in 
5 question to the ENUM subscriber, who can consult it on his terminal (8). 

Fig. 9 illustrates schematically the procedure for consultation and manual modification 
of an ENUM profile by UUI (User to User Information) fi"om an ISDN terminal (2). 

At step 600 the ENUM subscriber sends from his ISDN terminal (2) a telephone call 
containing the UUI information element to the ISDN interface (51). It should be recalled that 

10 the UUI field is currently limited to a size of 32 characters. The ENUM command which is 
inserted in the UUI field can therefore act on only one ENUM service at a time. For example: 
GetPl-33296053859*dupont#123456: this request makes it possible to recover the attributes 
of the priority 1 ENUM service. 

The calling automatic controller (52) at step 601 transmits the message requesting call 

15 establishment to the UUI module (53), which will extract the UUI conunand. The calling 
automatic controller (52) at step 652 sends the Alert message to the ENUM subscriber so as to 
allow a minimum amount of time (time delay with the ISDN protocol before sending a 
disconnection message). The UUI module (53) transmits the ENUM command at step 603 to 
the ENUM script module (75). The latter recovers the ENUM arguments supplied and then 

20 transmits them at step 604 to the authentication module (73). The authentication module (73) 
at step 605 interrogates the local or remote database (via an ODBC interface for example), 
making a search on the E.164 ENUM number. This supplies at step 606 the corresponding 
authentication information to the authentication module (73), which compares it with the 
pseudonym and password suppHed by the ENUM client in the UUI. In the case of agreement, 

25 the authentication module (73) advises the ENUM script module (75) of this at step 607. 
Subsequently the ENUM script module (75) sends an interrogation request at step 608 to the 
DNS protocol management module (62), supplying as an argument the E.164 address of the 
ENUM subscriber transformed in the form of a domain (transformation of the E.164 
telephone number of the type 33296053859 into 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). The DNS 

3 0 protocol management module (62) which fulfils the conventional role of a RESOLVER can 
(at step 609) interrogate without having checked whether the information is already in its 
cache following a previous consultation, using the DNS standard protocol (DNS Query 
request) the level 0 DNS and then the level 1 DNS, then the level 2 DNS via its DNS protocol 
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module (32). Preferably, in order to gain in efficiency, the data of a DNS server are loaded 
into the random access memory of the server (31). If the ENUM subscriber is actually 
recorded in the DNS (31) of the ENUM service provider (30), the DNS protocol stack (32) 
returns the corresponding NAPTR records at step 610 to the DNS protocol management 
5 module (62), which is responsible for retransmitting them to the ENUM script module (75) at 
step 611. The latter analyses and interprets the NAPTR records and, according to the service 
requested in the UUI command, generates a relatively synthetic text understandable to the 
ENUM subscriber, of the type: 

Service PI : Tel: 0296053859 

10 This text is sent at step 612 to the UUI module (53), which is responsible for 

formatting a disconnection message before sending it at step 613 to the calling automatic 
control module (52). The latter generates the ISDN disconnection message which contains 
the UUI information and which is therefore transmitted at step 614 via the ISDN network to 
the terminal (2) of the ENUM subscriber. The latter can display the UUI on the display of his 

15 ISDN terminal (2). 

The ENUM subscriber who wishes to modify his ENUM profile sends at step 650 
from his ISDN terminal (2) a telephone call containing the UUI information element to the 
ISDN interface (51). For example: DelP3-33296053859*dupont#l 23456: this request makes 
it possible to eliminate the priority 3 ENUM service. 

20 The calling automatic controller (52) transmits at step 651 a message requesting the 

establishment of a call to the UUI module (53), which extracts the UUI conmiand. The 
calling automatic controller (52) at step 652 sends the alert message to the ENUM subscriber 
so as to allow itself a minimum amount of time (timing of the ISDN protocol before sending a 
disconnection message). The UUI module (53) transmits the ENUM command at step 653 to 

25 the ENUM script module (75). The latter recovers the arguments supplied and then transmits 
them at step 654 to the authentication module (73). The authentication module (73) at step 
655 interrogates the local or remote database (via an ODBC interface for example), meJcing a 
search on the E.165 ENUM number. This supplies at step 656 the corresponding 
authentication information to the authentication module (73), which compares it with the 

30 pseudonym and password supplied by the ENUM client in the UUI. In the case of agreement, 
the authentication module (73) advises the ENUM script module (75) of this at step 657. 
Given that the modification does not relate to the entire profile, the ENUM script (75) first of 
all sends an interrogation request (at step 658) to the DNS protocol management module (62), 
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supplying as an argument the E.164 address of the ENUM subscriber transformed in the form 
of a domain (transformation of the E.164 telephone number of the type 33296053859 into 
9.5. 8.3. 5.0.6.9. 2. 3.3.el64.arpa). The DNS protocol management module (62), which fulfils 
the role of RESOLVER, can (at step 659), after having checked whether the information is 
5 already in its cache following a previous consultation, by means of the DNS standard protocol 
(DNS Query request), interrogate the level 0 DNS, the level 1 DNS and the level 2 DNS via 
its DNS protocol module (32). In order to gain in efficiency, the data of a DNS are loaded 
into the random access memory of the server (31). If the ENUM subscriber is actually 
recorded in the DNS (31) of the ENUM service provider (30), the DNS protocol module (32) 

10 at step 660 returns the corresponding NAPTR records to the DNS protocol management 
module (62). The latter is responsible for retransmitting them to the ENUM script module 
(75) at step 661. The ENUM script (75) then sends an update request taking account of the 
modification requested in the UUI field at step 662 to the DNS protocol module (62). The 
latter sends a DNS UPDATE command at step 663 to the DNS protocol module (32) of the 

15 DNS server (31) of the ENUM service provider (30). The IP address of the latter is stored in 
the database (70) and is found from the E.164 number of the ENUM subscriber. The DNS 
protocol module (32) updates the information in the random access memory of the server (31) 
and requests the updating of the database (33), which is generally a flat text file. The DNS 
protocol manages the modification number in this file so that the secondary DNS server or 

2 0 servers can themselves reload this modification at predefined intervals of time. The database 

(33) confirms the updating at step 665, which results in a response to the update request at 
step 666. The ENUM script (75) at step 667 intercepts the return code of this response and 
then at step 668 generates the confirmation/invalidation message relating to the taking into 
account of the modification. This message is sent at step 668 to the UUI module (53), which 
25 is responsible for formatting a disconnection message before sending it at step 669 to the 
calling automatic controller module (52). The latter at step 670 generates the ISDN 
disconnection message which contains the UUI information element and which is therefore 
transmitted via the ISDN network to the terminal (2) of the ENUM subscriber. The latter can 
display the UUI on the display of his ISDN terminal (2). 

3 0 Fig. 1 0 illustrates schematically the procedure for access to the service for consultation 

and automatic modification of an ENUM profile from a web session. The task consisting of 
manually modifying an ENUM profile can quickly become tricky and repetitive. An 
automatic controller (referred to as a configuration automatic controller) is then used to make 
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an automatic modification to the ENUM profile as a fiinction of time and/or other pareuneters. 
Amongst these other parameters, the location of the subscriber can be adopted if it is known 
to the system (50). 

At step 700 the ENUM subscriber requests the downloading of the home web page of 
the management service of the ENUM profile. This is returned at step 701 by the web server 
(63) of the present invention. This web page displays an authentication form to the ENUM 
subscriber. The latter enters his E.164 ENUM number and then his login and password. This 
information is transmitted at step 702 to the web server (63), which itself transmits it (at step 

703) to the authentication module (73). The authentication module (73) interrogates (at step 

704) the local or remote database (70) (via an ODBC interface for example) making a search 
on the E.164 ENUM number. This supplies at step 705 the corresponding authentication 
information to the authentication module (73), which compares it with the pseudonym and 
password entered by the ENUM client in the web form. In the case of agreement, the 
authentication module (73) at step 706 notifies the web server module (63) that the 
authentication has succeeded. The latter sends at step 707 to the ENUM script module (75) a 
request for reading the automatic configuration for this ENUM profile. The ENUM script 
module (75) at step 708 interrogates the database (70), supplying as arguments the E.164 
number of the ENUM subscriber. The database (70) at step 709 retums the automatic 
management program for the profile to the ENUM script module (75). The latter formats the 
information, for example: 

Monday to Friday: 0830 to 1900 
PI Tel 0296053859 
P2 Tel 0686166924 

P3 e-mail bertrand.dupont(S>rd.francetelecom.com 
P4 fax 0296050242 

Monday to Friday: 1900 to 0830 
PI Tel 0296916404 

P2 e-mail bertrand.dupont(alrd.fi-ancetelecom.com 



Saturday and Sunday: 0000 to 2359 
PI Tel 0296916404 
P2 Tel 0686166924 
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P3 e-mail b . dupontfatwanadoo . fr 

The ENUM script module (75) transmits the fomiatted infomiation at step 710 to the 
web server (63), which is responsible for downloading the web page containing the 
information in clear from the configuration program of the ENUM profile on the web terminal 
5 (8) of the ENUM subscriber. 

This web page allows modification of the automatic configuration program of the 
ENUM profile: changes to timetables, management of public holidays, addition/deletion of 
services, modifications of service attributes, etc. The ENUM subscriber validates the 
modification of the program at step 750. The web server (63) transmits this information at 
10 step 751 via the ENUM script module (75). The latter extracts the information and formats it 
in a defined format before writing it in the database (70), at step 752. This takes into account 
the recording of the program and confirms it at step 753 to the ENUM script module (75). 
The latter notifies the web server (63) of the taking into account of the modification of the 
configuration automatic controller of the ENUM profile. The server at step 755 downloads 
15 the web page confirming the modification on the web terminal (8) of the ENUM subscriber. 

Fig. 1 1 illustrates the procedure for automatic updating via the configuration automatic 
controller of the ENUM profiles as well as the optional procedure for notifying change of 
profile to the ENUM subscriber. 

The configuration automatic controller (74) regularly scrutinises the database (70) at 
20 step 800 in order to check whether there is a programmed modification to make (according to 
the current date and time). If a modification is programmed then the configuration parameters 
are returned at step 801. The configuration automatic controller (74) sends an interrogation 
request at step 802 to the DNS protocol management module (62), supplying as an argument 
the E.164 address of the ENUM subscriber whose profile is to be modified, transformed in the 

2 5 form of a domain name (transformation of the E.164 telephone number of the type 

33296053859 into 9.5. 8.3. 5,0.6.9.2. 3.3.el64.arpa). The DNS protocol management module 
(62) which fulfils the role of a RESOLVER can (at step 803), if however the information is 
not already in its cache following a previous consultation, by means of the DNS standsird 
protocol (DNS Query request), interrogate the level 0 DNS server, the level 1 DNS server and 

3 0 then the level 2 DNS server via his DNS protocol module (32). Preferably, in order to gain in 

efficiency, the data of a DNS are loaded into the random access memory of the DNS server 
(31). If the ENUM subscriber is actually recorded in the DNS (31) of the ENUM service 
provider (30), then the DNS protocol module (32) returns at step 804 the corresponding 
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NAPTR records to the DNS protocol module (62). The latter retransmits them to the 
configuration automatic controller (74), which then consults (step 806) the database (70) in 
order to recover the modifications to be made on the ENUM profile. The database returns 
(step 807) the profile to be applied to the configuration automatic controller module (74). If a 
5 modification is actually necessary (the profile has been able to be modified manually in the 
meantime), the configuration automatic controller determines the modifications to be made to 
the NAPTR records and sends an update request at step 808 to the DNS protocol management 
module (62). The latter sends a DNS UPDATE command at step 809 to the DNS protocol 
module (32) of the DNS server (31) of the ENUM service provider (30). The IP address of 

10 the latter is stored in the database (70) and is found from the E.164 number of the ENUM 
subscriber. The DNS protocol module (32) updates the information in the random access 
memory of the server (31) and requests the updating of the database (33), which is generally a 
flat text file. The DNS protocol manages the modification number in this file so that the 
secondary DNS server or servers can themselves reload this modification at predefined 

15 intervals of time. The database (33) confirms the updating at step 811, which results in a 
response to the update demand request at step 812. The configuration automatic controller 
(74) at step 813 intercepts the return code of this response and then at step 814 generates a 
request to write in the database (70) in order to supply the joumal of modifications. The 
database (70) confirms the writing of the profile automatic modification event at step 815. 

2 0 If the automatic update service has been configured in order to notify the automatic 

modifications to the ENUM profile, the configuration automatic controller notifies the 
updating according to one or more of the following modes: 

o in the case where the notification is in voice mode, the configuration automatic 
controller (74) notifies the calling automatic controller (52) at step 820, which 
25 results in a telephone call to an STN (4) or ISDN (2) or IP (7) fixed telephone, or 

to a mobile telephone (6). The notification information and addresses are stored in 
the database (70). The ENUM subscriber responds to this telephone call at step 
822 or the call is switched to its voice messaging. The voice synthesis module 
(55) or the voice file broadcast module (56) at step 823 broadcast the notification 

3 0 of the ENUM profile modification, for example: "hello, your ENUM profile 

33296053859 was updated today at 1900 as follows: telephone service to 
0296053859 and then telephone service to 0686166924 and then e-mail service to 
bertrand . dupo nt(ai wanadoo . fr " : 
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o in the case where the notification is in SMS mode, the configuration automatic 
controller (74) advises the SMS module (58) at step 830 by supplying the text of 
the SMS, for example of the type: "Modification of your ENUM profile 
33296053859 on 21/03/2002 at 0900: Tel: 0296053859, Tel: 0686166924, Fax: 
0296050242". The SMS module (58) at step 840 transmits this SMS message to 
the mobile or fixed telephone terminal, as configured in the database (70); 
o in the case where the notification is in e-mail mode, the configuration automatic 
controller (74) notifies the updating to the e-mail server (61) (step 850) by means 
of an e-mail containing a text of the type: "Modification of your ENUM profile 
33296053859 on 21/03/2002 at 0900: Tel: 0296053859, Tel: 0686166924, Fax: 
0296050242". To this end, the configuration automatic controller has an e-mail 
client. The e-mail server (61) then at step 860 transmits the e-mail in question to 
the e-mail address stored in the database (70); 
o in the case where the notification is in fax mode, the configuration automatic 
controller (74) notifies the fax module (59) at step 870, supplying the text of the 
fax, which could be of the type: "Modification of your ENUM profile 
33296053859 on 21/03/2002 at 0900: Tel: 0296053859, Tel: 0686166924, Fax: 
0296050242". The fax module (59) at step 880 transmits this fax to the fax 
terminal (9) configured in the database (70). 
Fig. 12 illustrates an example of a procedure for consulting the ENUM profile when 
the latter is stored in an LDAP directory. The example given in Fig. 12 illustrates a 
consultation via an individual computer but it is clear that the consultation can be carried out 
by means of other types of terminals previously envisaged. This type of service could in 
particular be offered by companies which wish to offer access to an ENUM service to all or 
some of their employees. 

The ENUM subscriber at step 900 requests the downloading of the home web page of 
the ENUM profile management service. This is returned at step 901 by the web server (63) of 
the system (50). This web page displays an authentication form for the ENUM subscriber. 
The latter enters his E.164 ENUM number and then his pseudonym and password. This 
information is transmitted at step 902 to the web server (63), which itself transmits it (step 

903) to the authentication module (73). The authentication module (73) interrogates (step 

904) the local or remote database (via an ODBC interface for example), making a search on 
the E.164 ENUM number. This supplies at step 905 the corresponding authentication 



information to the authentication module (73), which is responsible for comparing it with the 
pseudonym and password entered by the ENUM client. In the event of agreement, the 
authentication module (73) at step 906 notifies the web server module (63) that the 
authentication has succeeded. The latter at step 907 sends to the ENUM script module (75) an 
5 ENUM profile read request. The ENUM script (75) sends an interrogation request at step 908 
to the DNS protocol manaigement module (62), supplying as an argument the E.164 address of 
the ENUM subscriber transformed in the form of a domain (transformation of the E.164 
telephone number of the type 33296053859 into 9.5.8.3. 5.0.6.9.2.3. 3.el64.arpa). The DNS 
protocol management module (62) which fulfils the role of a RESOLVER interrogates (step 

10 909), if the information is not already in its cache following a previous consultation, by means 
of the DNS standard protocol (DNS Query request), the level 0 DNS server, the level 1 DNS 
server and then the level 2 DNS server via its DNS protocol module (32). Preferably, in order 
to gain in efficiency, the data of a DNS are loaded into the random access memory of the 
server (31). If the ENUM subscriber is actually recorded in the DNS server (31) of the 

15 ENUM service provider (30), the DNS protocol management module (32) at step 910 returns 
the corresponding NAPTR record or records. The DNS protocol management module (62) is 
responsible for retransmitting them to the ENUM script module (75) at step 911. The latter 
analyses and interprets the NAPTR record or records, for example: 
SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 

2 0 IN NAPTR 1 00 1 0 "u" 

"ldap+E2U»"!^.+33296053859$!ldap://ldap.providerA.fr/cn=33296053859!" 
The ENUM script detects that it is a case of an LDAP service. Consequently the 
ENUM script module (75) at step 912 sends to the LDAP protocol management module (64) a 
request LDAP demanding connection to the LDAP server referenced by the URI 

25 "ldap://ldap.pro viderA.fr". At step 913 the latter sends a request "Bind" to the LDAP 
protocol module (35) of the LDAP directory server (34) of the ENUM A supplier (30). The 
LDAP protocol module (35) accepts the connection at step 914. The LDAP protocol 
management module (64) then sends at step 915 to the LDAP protocol module (35) the LDAP 
request "Search" supplying the E.164 number of the ENUM subscriber as an argument. The 

30 LDAP protocol module (35) interrogates the LDAP database (36) at step 916 and then returns 
(at step 917) all the information concerning the ENUM subscriber to the LDAP protocol 
module (35), which itself returns it (step 918) to the LDAP protocol management module 
(64). The latter returns the information at step 919 to the ENUM script (75), which is 
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responsible for putting it in a form understandable to the ENUM subscriber before 
transmitting it (at step 922) to the web server (63). The server then downloads the web page 
generated dynamically at step 923 on the web terminal (8) of the ENUM subscriber. In 
parallel, the LDAP protocol management module (64) at step 920 sends a disconnection 
5 request to the LDAP server (34) via a request "Unbind". The LDAP protocol module (35) 
confirms the disconnection at step 92 L 

Fig. 13 describes the procedure for the manual modification of an ENUM profile when 
the latter is stored in an LDAP directory. There too, a modification of an ENUM profile by a 
terminal other than a PC can of course be envisaged. 

10 An ENUM subscriber who has previously consulted the content of his ENUM profile 

by means of the procedure described above may decide to modify it. To do this, he modifies 
locally in the web page displayed on the web terminal (8) the attributes of his ENUM services 
and the priorities and adds services or deletes some of them. He validates his profile 
modifications at step 1000 and the information supplied to the web server (63). The latter 

15 transmits all this information at step 1001 to the ENUM script module (75). The latter sends 
an interrogation request at step 1002 to the DNS protocol module (62), supplying as an 
argument the E.164 address of the ENUM subscriber transformed in the form of a domain 
(transformation of the E.164 telephone number of the type 33296053859 into 
9.5.8.3.5.0.6.9.2.3.3.el64.arpa). The DNS protocol management module (62), which fiilfils 

20 the role of a RESOLVER, can, if the information is not already in its cache following a 
previous consultation (at step 1003), with the DNS standard protocol (DNS Query request), 
interrogate the level 0 DNS, then the level 1 DNS, before interrogating the level 2 DNS via its 
DNS protocol module (32). To gain in efficiency, the data of a DNS are loaded in the random 
access memory of the DNS server (31). If the ENUM subscriber is actually recorded in the 

25 DNS (31) of the ENUM service provider (30) the DNS protocol module (32) at step 1004 
returns the corresponding NAPTR record or records. The DNS protocol management module 
(62) then retransmits them to the ENUM script module (75) at step 1005. The latter analyses 
and interprets the NAPTR record or records, for example: 
SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 

30 IN NAPTR 100 10 "u" 

"ldap+E2U""!^.+33296053859$!ldap://ldap.providerA.fi-/cn=33296053859!" 
The ENUM script module (75) detects whether it is a case of an LDAP service. The 
ENUM script module (75) then sends (step 1006) to the LDAP protocol module (64) an 
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LDAP request demanding connection to the LDAP server referenced by the URI 
"IdaprZ/ldap.providerA.fr". The latter at step 1007 sends a request "Bind" to the LDAP 
protocol module (35) of the LDAP directory server (34) of the ENUM A supplier (30). The 
LDAP protocol module (35) accepts the connection at step 1008. The LDAP protocol module 
5 (64) then at step 1009 sends to the LDAP protocol module (35) an LDAP request "Search", 
supplying the E.164 number of the ENUM subscriber as an argument. The LDAP protocol 
module (35) interrogates the LDAP database (36) at step 1010 and then at step 101 1 retums 
all the information conceming the ENUM subscriber to the LDAP protocol management 
module (35), The latter retums it at step 1012 to the LDAP protocol management module 

10 (64), which itself retums it (step 1013) to the ENUM script module (75). The latter compares 
it with the information supplied via the web by the ENUM subscriber and determines the 
operation to be performed to the LDAP format and transmits a modification request at step 
1014 to the LDAP protocol management module (64). The latter sends an LDAP request 
"Modify" at step 1015 to the LDAP protocol module (35), which itself at step 1016 sends a 

15 request to write in the database (36). The latter accepts the updating and confirms it (step 
1017) to the LDAP protocol module (35). The latter transmits (step 1018) the 
confirmation/invalidation conceming updating to the LDAP protocol management module 
(54), which retums it (step 1019) to the ENUM script module (75). The latter then generates 
the modification confirmation web page before transmitting it to the web server (63). The 

20 server downloads this page (step 1023) to the web terminal (8) of the ENUM subscriber. In 
parallel, the LDAP protocol module (64) sends (step 1020) a disconnection request to the 
LDAP server (34) via a request "Unbind". The LDAP protocol module (35) confirms the 
disconnection at step 1 02 1 . 

Although the procedure for updating the LDAP directory or has been illustrated for a 

25 "manual" procedure , it goes without saying that an automatic updating of the LDAP directory 
by means of the configuration automatic controller (74) can also be envisaged. 

Although the invention has essentially been described in the context of the "ENUM" 
application and the updating of the ENUM profile, it is clear to a person skilled in the art that 
it can be extended to the updating of one or more resource records (RR) in a DNS (or LDAP) 

3 0 server, as defined in paragraph 3.2.2 of the aforementioned document RFC 1035 and set out in 
the table below: 
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Type of RR 


Value 


Meaning 


A 


1 


IP address of a machine 


NS 


2 


Name of server managed by an administrative authority 


MD 


3 


Destination mail server 


MF 


4 


Rerouting mail server 


CNAME 


5 


Canonical name for an alias 


SOA 


6 


Marks start of an area of authority 


MB 


7 


Domain name of an e-mail box 


MG 


8 


Member of mail group 


MR 


9 


Domain name renaming a mail 


NULL 


10 


Resource record NULL 


WKS 


11 


Well-known service description 


PTR 


12 


Pointer to a domain name 


HINFO 


13 


Information on a computer machine 


MINFO 


14 


Information on a mail box 


MX 


15 


Mail exchange 


TXT 


16 


Character strings 



For a given resource record, the updating can relate to one or more fields of this 
record, as defined in the aforementioned document RFC 1035. 

It should be noted that, if the updating of a resource record or records other than 
5 NAPTR is envisaged, new modules similar to the module "ENUM Script" (75) and "ENUM 
configuration automatic controller" (74) must be added to process each of these records. 



